Celestin Apprentice 5/Apprentice-Release5.iso/Information/THINK C Digest/1990/90-11

Text File | 1995-12-31 | 63KB | 1,842 lines

Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Bug in CBartender?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 7 Nov 90 17:51:00 GMT

I've just had a quick look at CBartender. It has a table mapping menu items
to commands, and it uses SetHandleSize() to alter the size of the table,
but doesn't check that an attempt to increase the size always succeeds (it
might fail if the handle's storage is right next to a non-relocatable
block). This looks rather nasty. Should I be worried?

Nick.










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: The CBartender thing...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 21
Date: 8 Nov 90 11:28:09 GMT

The jury seems to be out on this one (judging by the replies I've received
- thanks, everybody).

The general concensus seems to be that SetHandleSize can relocate a handle
past a nonrelocatable block to un-landlock it. I seem to recall that
handles never move over fixed blocks, though. I'll have to check IM II to
see if that's different for SetHandleSize.

If SetHandleSize fails due to the above, some respondents reckoned the
memory manager would be asked to make room; but, if the fixed blocks don't
go away, I don't see what good this will do. Another reply claimed that a
failing SetHandleSize causes the Memory Manager to report an error. Maybe,
but I seem to recall that the description of the SetHandleSize trap says
that it should be checked for failure. My copy of IM II is at home
(needless to say...)

I doubt this is going to be a big problem in practice, but it might just
take something like: create a new window (WindowRec's can't be relocated)
and then insert a new menu for it... *blam*.

Nick.










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: The CBartender thing...
Message-ID: <[e-mail]>
In-Reply-To: Nick Rothwell's message of 8 Nov 90 11:28:09 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 8 Nov 90 14:48:58 GMT

If SetHandleSize fails (in CBartender::AddMenu()) for lack of memory,
the CApplication's GrowZoneProc will be invoked.  Since we didn't say
that we wanted to handle the memory failure ourselves (by using
CApplication::RequestMemory()), the GrowZoneProc will put up a dialog
and quit the program.  I think.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: MIDI Manager programmers - anybody home?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 28
Date: 12 Nov 90 11:13:16 GMT

Well, it's been a couple of years since Apple announced the MIDI Manager,
and well over a year since it's been available (does that mean Apple have
been in court over it for that long? Oh well...). Given that the Macintosh
is pretty much the US standard machine for MIDI programming (except in
Europe where people buy machines that they can actually afford instead),
and given that MIDI Manager is quite easily available and quite easy to
work with, where are all the bits and pieces of shareware/freeware? I have
seen exactly two in the last year - a simple channelising echo application,
and MacMuse. Is nobody else using it? Is everyone else rolling their own
serial port drivers (yuck!)?

So. I want to talk about MIDI Manager programming, if anyone else is
interested. Last year I wrote a generic editor/librarian using it, and I'm
just finishing a complete re-write using the THINK Class Library. It uses a
big chunk of the MIDI Manager facilities; for example, to transmit a patch
bank, it does buffering of its output and allows MIDI Manager to send the
MIDI data asynchronously into the future (up to the capacity of the output
buffer) using a WakeUp task - a lot more sexy than busy-loops and
spin-waits.

I'll even offer to (gosh!) share the source code for all of this - but only
if we get talking, OK? (last time I got large numbers of requests for the
code and I have no idea if anybody did anything with it or what...) MIDI
Manager is too important to be ignored, so let's get cooking.

Anybody got any up-to-date news on the court case?

Nick.










Path: ucivax!gateway
From: [e-mail] (SCHABTACH ADAM)
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 40
Date: 13 Nov 90 06:17:20 GMT

Subject: Re: MIDI Manager programmers - anybody home?


>work with, where are all the bits and pieces of shareware/freeware? I have
>seen exactly two in the last year - a simple channelising echo application,
>and MacMuse.

I ran across a third recently -- a Mac implementation of KeyFrets, that
program originally written on a C-64 to make a MIDI keyboard act a
bit like a guitar.

>So. I want to talk about MIDI Manager programming, if anyone else is
>interested.

I'm interested (Nick, you probably already guessed that).

>I'll even offer to (gosh!) share the source code for all of this - but only
>if we get talking, OK? (last time I got large numbers of requests for the
>code and I have no idea if anybody did anything with it or what...) MIDI
>Manager is too important to be ignored, so let's get cooking.

Well, I still keep a printed version of your source code and refer to it
when I start messing with the MIDI Manager. That code and the arpeggiator
program that comes with the MM is how I learned enough to write MacMuse.
(BTW, you shouldn't feel too bad about not hearing from people who
requested your code -- I sent about a dozen copies of MacMuse to people
who asked for it, and got *one* response from someone saying they actually
got it up and running, and gave it more than a few minutes' attention.)

>Anybody got any up-to-date news on the court case?

As of this issue of MacWeek, it's still being negotiated. :-( Apparently
Apple Computer is trying to get Apple Corps to reliquish their copyright
in some European countries, for reasons they won't disclose.

I've heard that v2.0 of the MIDI Mgr. is about to be released, or has
been already. Anyone know about this?

--Adam











Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: MIDI Manager 2.0
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 45
Date: 13 Nov 90 14:46:56 GMT

>Well, I still keep a printed version of your source code and refer to it
>when I start messing with the MIDI Manager. That code and the arpeggiator
>program that comes with the MM is how I learned enough to write MacMuse.

I'm currently rewriting my MIDI Driving code to eliminate the spin-waiting
that I was using to space out the transmission of SysEx packets. The
problem is that response to the user when selecting patches should be very
fast, even if the packets have to be staggered for output. I can't use MIDI
Manager's timestamping directly - sending packets with future timestamps
would be OK, *except* that I do realtime echoing of MIDI channel data as
well, and I don't want interference with outgoing continuation packets
stamped to coincide with it. Also, there's no *proper* way of testing the
destination buffer (there may be more than one) for capacity - you have to
transmit and trust it, guessing a reasonable delay time. So, transmitting
an entire patch bank using MIDI Manager's send-ahead will almost certainly
fail. What I do now is queue the packets for output in a circular buffer,
and then use a WakeUp task to actually send them out, in the same way the
MIDIArp demo schedules itself WakeUp tasks to do the arpeggiation (but
without sending anything into the future, which MIDIArp does).

>(BTW, you shouldn't feel too bad about not hearing from people who
>requested your code -- I sent about a dozen copies of MacMuse to people
>who asked for it, and got *one* response from someone saying they actually
>got it up and running, and gave it more than a few minutes' attention.)

Aw, I got it up and running as well, but haven't gotten around to puzzling
out what it actually does yet...! I may start using it as a test
application to hammer my MIDI echoing routines. After that, I'll run
Performer through them and try some fast sequencing...

I'll send out my code to anybody who's interested as soon as I've made sure
it's solid. At the moment it hangs periodically while trying to clear the
output buffers - presumably some critical section problem somewhere causing
the WakeUp task to terminate. Right now, I have what must be the only MIDI
librarian which can actually load a synthesiser while unloading from
another one...

>I've heard that v2.0 of the MIDI Mgr. is about to be released, or has
>been already. Anyone know about this?

I've been told that in a roundabout way by a contact at MOTU. I've asked a
developer contact of mine to chase up APDA here in the UK to find out.
("MIDI Manager? What's that?") More to follow when I hear something.

Nick.










Path: ucivax!gateway
From: [e-mail] (SCHABTACH ADAM)
Subject: Graphic controls?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 13 Nov 90 16:10:36 GMT


I'm thinking about a project that will involve nonstandard scroll bar-like
controls. (Why? Well, they look nifty, and I'm trying to emulate a piece
of hardware.) What I want is basically something like the Volume slider in
the Control Panel, but I need more resolution (i.e. a range of 0-127 rather
than 0-7). I imagine I could write it myself, but it would save some valuable
time if I could use someone else's code. Has anyone written or seen a class
to do this?

Thanks,
--Adam










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: MIDI Manager
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 13 Nov 90 18:47:53 GMT

I've just been told that...

>    The word from APDA in the US is that Midi Manager 2.0 will be
>released later this month.

Nick.










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Graphic controls?
Message-ID: <[e-mail]>
In-Reply-To: SCHABTACH ADAM's message of 13 Nov 90 16:10:36 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 13 Nov 90 19:19:33 GMT

Check out the article in August 1990 MacTutor (vol 6 no 8).  There's
an article in there that describes writing a class for a meter-type
control.  The control has a numeric readout that can be typed into,
and the arrows automatically speed up after a certain amount of time.
Even if this isn't what you're looking for, it should give you a head
start.

    -phil










Path: ucivax!gateway
From: [e-mail]
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 2
Date: 14 Nov 90 20:50:27 GMT













Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: MIDI Manager question (yup, me again...)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 15 Nov 90 17:34:47 GMT

Hi there. Me again, with a MIDI Manager question.

The MIDIWakeUp() call (which lets you attach a routine to a periodic or
one-time time advance on a time port) - can you have more than one attached
to a time port at once? I'm inclined to doubt it (where would MM allocate
the space for the information, given that MIDIWakeUp() can be called at
interrupt) - but, the documentation doesn't give anything away, and the
MIDIArp demo program explicitly cancels WakeUp tasks even if they're
non-periodic, one-time ones.

I've had problems which might be associated with the way that I happily
call MIDIWakeUp() on a time port regardless of whether any wake-up routine
is queued or not, expecting any outstanding one to be cancelled. If only
one can be queued at a time, there's no problem, but...

Anybody have any clues?

Nick.










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: Bugs in CPicture?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 6
Date: 19 Nov 90 13:41:13 GMT

I've had the TCL class CPicture bomb on me. I had a quick look at the
source, and its Dispose() method always calls KillPicture(). Inside Mac
says that ReleaseResource() should be used for resource-based pictures
(which I was using). Is CPicture out of line, or is it me?

Nick.










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Bugs in CPicture?
Message-ID: <[e-mail]>
In-Reply-To: Nick Rothwell's message of 19 Nov 90 13:41:13 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 17
Date: 19 Nov 90 15:57:15 GMT

You are entirely correct, CPicture is buggy.  Currently, there is no
fix for it.  If you are constructing a picture on the fly (using
CPicture::SetMacPicture()), then the code will work as it stands.  If
you are using a resource file, you should override CPicture::Dispose,
so it just uses ReleaseResource().  This is how I would write it:

void    RsrcCPicture::Dispose()
{
    ReleaseResource(macPicture);
    CPanorama::Dispose();         /* this can't be done in Pascal! */
}

The second line is a direct superclass call.  It should be avoided
whenever possible, but here it is necessary (unless we modify the
TCL).

    -phil










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: About-Box Blues
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 22
Date: 19 Nov 90 19:34:02 GMT

How are y'all doing your about-boxes? Are there any interface guidelines
about this?

I wanted something a little sexier than the usual modal dialog. In which
case, it becomes important to figure out whether to grab control of the Mac
for the duration of the about-box, or what...

For the time being, I've implemented a similar one to the Art Class demo -
i.e., create a director and window, bring it to the front, draw into it
directly, and spin-wait until a key or mouse event (I tried a CPicture, but
think these are buggy - see previous posting - so I might use a sub-class
to avoid the bug). The problem I've had is that the underlying document
window gets partially deactivated after the about-box has gone, and the
mouse coordinate environment seems to get nuked for window clicks. Art
Class seems to get this right (although Desk Accessories confuse it a
little), so I'll give this a closer look.

Any reason why I *shouldn't * implement a spin-wait about-box?

If it's good enough for THINK C, it's good enough for me...

Nick.










Path: ucivax!gateway
From: [e-mail] ("Michael W. Groff")
Subject: include me in the mailing list
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 3
Date: 20 Nov 90 02:08:31 GMT

Please add me to the think-c mailing list.
Thanks,
mike










Path: ucivax!gateway
From: [e-mail] (Evan James Torrie)
Subject: Think C mailing list
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 20 Nov 90 06:12:57 GMT

Can I subscribe to this list?


--
------------------------------------------------------------------------------
Evan Torrie.  Stanford University, Class of 199?       [e-mail]
Fame, fame, fame...  What's it good for?  Ab-so-lute-ly nothing










Path: ucivax!gateway
From: [e-mail]
Subject: CPicture Bugs
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 20
Date: 20 Nov 90 07:34:30 GMT

The buggy Dispose() method was added by the infamous 4.0.2 THINK C update.
Previously, CPicture had no Dispose() method, and this is still the case
with the current Pascal version.

The solution is not straightforward. The reason that the Dispose() method
was left out in the original version was to avoid killing or releasing
a PICT that might be used in another window. It was not an oversight. A
common use for CPicture is to have a header picture at the top of each
window (perhaps a company logo). Closing one window should not kill (or
release the picture), since that same picture is used in the other open
windows. I couldn't come up with a clean solution for dealing with a
resource that could have multiple users. Some sort a reference count is
needed so that the resource is released only when there are no more
references to it. I opted for the simple, memory wasteful, solution of
not releasing it at all. Apparently, Symantec thought that not killing
(or releasing) the picHandle upon disposing of the CPicture was an oversight,
so they "corrected" it in the 4.0.2 update. My mistake was not documenting
the reason for the omission.

-- Greg










Path: ucivax!gateway
From: [e-mail] (Ray Beausoleil)
Subject: THINK C Mailing List
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 8
Date: 20 Nov 90 14:31:51 GMT


I just read a note on comp.sys.mac.programmer that I could join a THINK C
mailing list at this address. Is this true? If so, how do I sign up?

Thanks,

Ray Beausoleil
[e-mail]










Path: ucivax!gateway
From: [e-mail] (David Byers)
Subject: Please add me to the mailinglist
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 5
Date: 20 Nov 90 19:46:07 GMT

Please add me to the THINK C mailinglist.

David Byers

[e-mail]










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: About-box Blues
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 23
Date: 20 Nov 90 20:51:41 GMT

Thanks to the folks who replied to me about this (and also about the
CPicture bug).

Regarding the About-box - using the TCL as-is wasn't good enough, since I
wanted to throw up the about-box when my application started and get rid of
it when coming into the event loop (yup, even on my SE/30, my application
is big and complicated enough to make this a reasonable delay). The TCL
wouldn't draw the picture until a refresh. So, my trick was to create a
CDirector, allocate a window, bring the window to the front, and draw
directly into it - a bit easier than using a (fixed) CPicture.

The problem I was having was that doing the about-box by creating a
CDirector, selecting its window, spin-waiting until Button() or key-click,
and then nuking the director, wasn't working. The underlying document
window would then deactivate and go into an inconsistent state. Finally, I
twigged what Greg Dow did in the Art Class - use the floating window
desktop, and make the about-box a floating window, to avoid screwing the
other windows. Nice one. Problem fixed.

The spin-wait code is just lifted from Art Class (however, it exits when
the command or control key is hit - I think this is wrong...)

Nick.










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: MIDI Manager problem - found it...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 38
Date: 20 Nov 90 20:51:53 GMT

[I didn't see this message come past on the list (although I saw my other
two),
 so perhaps it got lost. Apologies if you see it twice.
]

Think I found my MIDI Manager timing problem. This is an interesting one:

I have an output buffer for MIDI packets, and it's serviced by an interrupt
routine, so that the application can respond immediately to the user while
queueing packets for transmission some time into the future. When a packet
is queued, I had a call something like the following:

   MIDIWakeUp(refNum, MIDIGetCurTime() + 1, 0, &myTimeHook);

That schedules a call to myTimeHook 1 tick (1 msec, in fact) into the
future, cancelling any existing schedule. The "+ 1" makes sure that the
hook isn't scheduled exactly at the present time (in which case, it
wouldn't get called, unless the time was rolled backwards....).

I was getting periodic hangups on my SE/30, and repeatable hangups on a Mac
Plus. It then occurred to me that the above was unsafe - what if the clock
ticks between the call to GetCurTime() and WakeUp()? So, I turned it into a
"+ 2", assuming that any Mac should be able to assemble arguments to a
procedure in at most a millisecond...!

Problem fixed on the SE/30, *except* when running the debugger...

I've now rewritten this part of the code in a different way, and it seems
solid on the SE/30 and the Plus.

The lesson here: check your critical sections and timing conditions
carefully (always the case with interrupt programming), *and* : expect the
debugger to grab control from you for milliseconds at a time.

Can somebody in the know actually confirm that the debugger is doing this?
If not, the problem is/was more complex that I guessed...

Nick.










Path: ucivax!gateway
From: [e-mail] (Greg Restall)
Subject: Think C Mailing list???
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 20 Nov 90 21:07:08 GMT


I heard that it was possible to get on a Think-C mailing list
via this address.  Is this correct?  If so, what do I do?  Anyway,
jut to make sure, mu address is [e-mail] -- Thanks
a bunch.

Greg Restall.










Path: ucivax!gateway
From: [e-mail]
Subject: request
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 5
Date: 20 Nov 90 21:42:42 GMT

please add me to the think c mailing list.
sorry if i sent this to the wrong place.

Ian Dowell
[e-mail]










Path: ucivax!gateway
From: [e-mail] (William L Nussbaum)
Subject: Mailing List
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 1
Date: 20 Nov 90 22:43:58 GMT

help










Path: ucivax!gateway
From: [e-mail] (Brent William Schorsch)
Subject: I would like to be on your mailing list
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 2
Date: 21 Nov 90 08:04:18 GMT

I understand that you have a mailing list (copm.sys.mac.programmer 11/19)
please add me to the list










Path: ucivax!gateway
From: [e-mail] (Paul Vowles)
Subject: Interfacing to other languages
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 11
Date: 21 Nov 90 11:01:04 GMT


I need to buy a C compiler for the Mac ... but it must be able to interface
to AbSoft Fortran (by order of my Boss). Does Think-C provide such an
interface ?? What is the best/most cost effective C compiler for this ??

                        Thanks

                        Paul Vowles

                        [e-mail]











Path: ucivax!gateway
From: [e-mail] (Mark Hartman)
Subject: Please add me to mailing list
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 7
Date: 21 Nov 90 12:36:23 GMT

Hi there:

I hope I'm going about this in the right way - I'd like to be added to the
THINK C mailing list.

Thanks.











Path: ucivax!gateway
From: [e-mail]
Subject: Please add me to the list
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 16
Date: 21 Nov 90 14:07:21 GMT
X-Vmsmail-To: SMTP%"[e-mail]"


 Hello,

 Could you please add me to your Think C mailing list.

 Thanks in advance.

 Regards,
 Malcolm

_________________________________________________________________
    Malcolm Pradhan                               _--_|\
    Medical Informatics, Faculty of Medicine     /      \
    University of Adelaide, South Australia      \_.--._/
    InterNet: [e-mail]               v
    Fax: + 618 338 2108










Path: ucivax!gateway
From: [e-mail] (Amir Kishon)
Subject: Text processing
Full-Name: Amir Kishon
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 14
Date: 21 Nov 90 16:49:03 GMT

I am looking for some TCclasses/sample code/ideas about implementing
TextEdit like procedures that do not have the Mac-TextEdit limitations
(i.e.  are not limited to 32K characters, have better performance
etc.). Actually any pointers about implementing text processors in
think-c would be greatly appreciated.  I already know about two
commercial packages that do exactly that - the prepare() magazine and
a Canadian company (which I forgot its name) packages. Unfortunately
they cost not a trivial amount of $$$.

Thanks,

-amir












Path: ucivax!gateway
From: [e-mail] (Neil Cohen)
Subject: ANSI Library problem
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 34
Date: 21 Nov 90 17:50:04 GMT

Hi,

I'm relatively new to programming on the Mac. We recently purchased
Think C 4.0, and I'm running on a Mac IIfx.

I ported a small program from my Unix system which builds and scans
a directed graph. The program was building lots of trees, adding and
discarding nodes as it worked its way through the graph. I found that
I was running out of memory. A short test program (discarded, but I
can redo it, it was only about 10 lines of code) showed that once
memory was 'malloc'ed, then 'free'd, the next call to malloc did not
re-acquire the same memory (all mallocs in my pgm were for the same size
structure). I changed the mallocs to 'NewPtr', and the memory
leak went away.

Is this a known problem? How often (if ever) is the ANSI library updated?

I'm also having some serious problems with fread/fwrite in a different program.
Are there any known problems with those routines?
I will finish documenting my trouble and will be asking for help
on it later today or tomorrow.

Thanks,

nbc

NAME:   Neil B. Cohen (Tracor Applied Sciences)
PHONE:  [phone]
DOMAIN: [e-mail]
*************************************************************
* Murphy's Philosophy: Smile - tomorrow will be worse...    *
*                                                           *
* O'Tooles Commentary: Murphy was an optimist!              *
*************************************************************










Path: ucivax!gateway
From: [e-mail] (Mark Nagel)
Subject: ARCHIVE: NBP sample code
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Reply-To: [e-mail]
Organization: University of California, Irvine - Dept of ICS
Lines: 19
Date: 21 Nov 90 19:01:42 GMT
Phone: [phone]

This is a silly little example of how to use the Inside Mac V
(preferred) Appletalk routines, specifically NBP. It conforms
to nobody's interface guidelines.

the program (I hesitate to even call it that) looks up all names
not associated with the node on which it is run, and prints them
to stdout. Known bugs include a propensity to hang when the names
table is inconsistent (name duplication) and a failure of the
SetSelfSend function to, well, SetSelfsend. Suggestions welcome.

Since the documentation in IM is, to say the least, confusing,
and since I've often seen requests for this type of thing in
CSMP and CSMC, I think this should help some people out.

A better version will be soon forthcoming,
Source is Think-C 4.02
-Rens Troost.

[saved as: /mac/think-c/examples/nbp_sample_code.hqx]










Path: ucivax!gateway
From: [e-mail] (Neil Cohen)
Subject: Problems with fread/fwrite...?
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 167
Date: 21 Nov 90 19:22:19 GMT

Hi,

Enclosed are 2 programs that are giving me fits. I'd be much obliged
if someone can point out what I'm doing wrong, or whether I've run into
a bug in Think C 4.0. For what it is worth, this code runs properly
on my U*ix box.

The first program writes a binary file with (ANSI) fwrite(). The binary
records are 16 (4 byte) words long and contain the following pattern:

0x00000000  0x01010101  0x02020202  0x03030303
0x04040404  0x05050505  0x06060606  0x07070707
0x08080808  0x09090909  0x0a0a0a0a  0x0b0b0b0b
0x0c0c0c0c  0x0d0d0d0d  0x0e0e0e0e  0x0f0f0f0f

Simple enough. I wrote out 1025 records - just over 64K of data.
Then I looked at the file with the QuickView Desk Accessory.
The Hex Dump shows that the records look like this:

0x00000000  0x01010101  0x02020202  0x03030303
0x04040404  0x05050505  0x06060606  0x07070707
0x08080808  0x09090909  0x0d0d0d0d  0x0b0b0b0b
                        ^^^^^^^^^^ wrong!
0x0c0c0c0c  0x0d0d0d0d  0x0e0e0e0e  0x0f0f0f0f

Absolutely wrong!

So I wrote a second program in Think C. It fopens the binary
file, freads 16 (4 byte) words at a time, and compares them with
the pattern that I thought I had written out.

The output is the following:

========== Start output =====================
Error: Word 13 S/B 0d0d0d0d  IS 0a0a0a0a (also word 29, 45 etc..
                                          i.e. every 0d0d0d0d word)

SHOULD BE:
0x00000000  0x01010101  0x02020202  0x03030303
0x04040404  0x05050505  0x06060606  0x07070707
0x08080808  0x09090909  0x0a0a0a0a  0x0b0b0b0b
0x0c0c0c0c  0x0d0d0d0d  0x0e0e0e0e  0x0f0f0f0f

ACTUAL
0x00000000  0x01010101  0x02020202  0x03030303
0x04040404  0x05050505  0x06060606  0x07070707
0x08080808  0x09090909  0x0a0a0a0a  0x0b0b0b0b
                        ^^^^^^^^^^ -> not what Quickview saw!
0x0c0c0c0c  0x0a0a0a0a  0x0e0e0e0e  0x0f0f0f0f
            ^^^^^^^^^^ -> where did this come from?
========== End output =====================

The Think Debugger believes that the data written out by the first program
is correct (i.e. 0, 1, 2, 3...d, e, f at the call to fwrite). It also
believes that word 13 of the second program is WRONG i.e. the file
contains 0a0a0a0a where it should contain 0d0d0d0d. But word 10, which
Quickview thinks contains 0d0d0d0d (incorrect) seems to contain
0a0a0a0a (correct) in the Think C program.

HELP!!!!! What is going on here?

Unless this is a major library problem, please respond
directly to me. I'll send a summary if it seems appropriate
(that means, if I didn't do something so stupid that I'm
ashamed to ever see my name on the network again...  :)

Thanks in advance, source code (about 90 lines total) follows .sig

nbc

NAME:   Neil B. Cohen (Tracor Applied Sciences)
PHONE:  [phone]
DOMAIN: [e-mail]
*************************************************************
* Murphy's Philosophy: Smile - tomorrow will be worse...    *
*                                                           *
* O'Tooles Commentary: Murphy was an optimist!              *
*************************************************************

======== write_binary.c ======

#include <stdio.h>
#include <string.h>

FILE *Ofd;
char *fname = "Binary.Dat";

long binvar[16] = { 0x00000000, 0x01010101, 0x02020202, 0x03030303,
                    0x04040404, 0x05050505, 0x06060606, 0x07070707,
                    0x08080808, 0x09090909, 0x0a0a0a0a, 0x0b0b0b0b,
                    0x0c0c0c0c, 0x0d0d0d0d, 0x0e0e0e0e, 0x0f0f0f0f };

long Loop_count = 1025;

main(){
    register int i;

    printf("Loop_count = %ld\n", Loop_count);

    Ofd = fopen(fname, "w");
    if(Ofd == NULL){
        printf("Failed to open %s\n", fname);
        exit(1);
    }

    for(i = 0; i < Loop_count; i++){
        fwrite(&binvar[0], sizeof(binvar[0]), 16, Ofd);
    }
}

======== read_binary.c ======

#include <stdio.h>
#include <string.h>

FILE *Ifd;

char *ifname = "Binary.Dat";

long binary[16] = { 0x00000000, 0x01010101, 0x02020202, 0x03030303,
                    0x04040404, 0x05050505, 0x06060606, 0x07070707,
                    0x08080808, 0x09090909, 0x0a0a0a0a, 0x0b0b0b0b,
                    0x0c0c0c0c, 0x0d0d0d0d, 0x0e0e0e0e, 0x0f0f0f0f };

long binary_input[16];
long Loop_count = 1025;
long Word_count;

main(){
    register int i, j, k;
    char string[20];

    printf("Loop_count = %ld\n", Loop_count);

    Ifd = fopen(ifname, "r");
    if(Ifd == NULL){
        printf("Failed to open %s\n", ifname);
        exit(1);
    }

    for(Word_count = 0, i = 0; i < Loop_count; i++){
        fread(&binary_input[0], sizeof(binary_input[0]), 16, Ifd);
        for(j = 0; j < 16; j++){
            if(binary_input[j] != binary[j]){
                printf("Error: Word %ld S/B %lx   IS %lx\n",
                        Word_count, binary[j], binary_input[j]);
                printf("SHOULD BE:\n");
                for(k = 0; k < 16; k++){
                    printf("%8lx  ", binary[k]);
                    if(k == 7)
                        printf("\n");
                }
                printf("\nACTUAL:\n");
                for(k = 0; k < 16; k++){
                    printf("%8lx  ", binary_input[k]);
                    if(k == 7)
                        printf("\n");
                }
                printf("\n\nContinue? ");
                gets(string);
                if(string[0] != 'y')
                    exit(1);
            }
        }
        Word_count++;
    }
}










Path: ucivax!gateway
From: [e-mail] (Neil Cohen)
Subject: Problem w/fread and fwrite
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 21
Date: 21 Nov 90 22:25:38 GMT

Regarding the two short programs I sent in earlier this afternoon,

My thanks to Mark Nagle who pointed out that I needed to open the file
with fopen(name, "wb") to force binary mode.
                   ^

Since I had just copied the program from my U*ix box, I had only
used "w". Pgm works properly now.

Much obliged for the help,

nbc

NAME:   Neil B. Cohen (Tracor Applied Sciences)
PHONE:  [phone]
DOMAIN: [e-mail]
*************************************************************
* Murphy's Philosophy: Smile - tomorrow will be worse...    *
*                                                           *
* O'Tooles Commentary: Murphy was an optimist!              *
*************************************************************










Path: ucivax!gateway
From: [e-mail] (Neil Cohen)
Subject: Fread/fwrite
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 5
Date: 22 Nov 90 00:38:18 GMT

For the record - several different people responded telling me
about the "wb" mode in fopen. Thanks to all for the very prompt
response.

nbc










Path: ucivax!gateway
From: [e-mail] ("Jan G. Zegers")
Subject: subscribe
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
X-VMS-To: [e-mail]
Lines: 2
Date: 22 Nov 90 08:57:32 GMT
X-Envelope-to: [e-mail]

subscribe [e-mail]











Path: ucivax!gateway
From: [e-mail] (opcode ranger)
Subject: Question regarding definition of LongDateTime
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 20
Date: 23 Nov 90 00:42:01 GMT
X-Vmsmail-To: @THINKC

In "ScriptMgr.h" LongDateTime is defined as

    typedef struct { long comp[2]; } LongDateTime;

but in the script manager guide from Apple it's defined as

    typedef comp LongDateTime;

Why the workaround to simulate a comp?  And for that matter, where is comp
actually defined?  I looked in "SANE.h" but couldn't find it there; in THINK
Pascal that's where it's defined (well, SANE.p actually :->).

Since this is a simple question, if you could mail me an answer it would
probably be best, so as not to clog up the list.

Thanks!

Robert

[e-mail]










Path: ucivax!gateway
From: [e-mail] (Dmitri Linde)
Subject: Think C browser?
Message-ID: <[e-mail].>
Posted-Date: Sun, 25 Nov 90 11:13:18 CST
Newsgroups: fa.think-c
Lines: 8
Date: 25 Nov 90 17:23:17 GMT

Hi!

  I was told that there exists a class browser for Think C...
Anyone has it?

     Thanks,
 - Dmitri
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Think C browser?
Message-ID: <[e-mail]>
In-Reply-To: Dmitri Linde's message of 25 Nov 90 17:23:17 GMT <[e-mail].>
Newsgroups: fa.think-c
Lines: 20
Date: 26 Nov 90 15:42:31 GMT

The only class broswer that I'm aware of is the broswer that comes
with MacApp (formerly called Mouser, now called MacBrowse (tm)).  This
class browser works with Think C after you make two changes to your
sources:

(1) Add "#define class struct" to, say, <oops.h>.

(2) Change all object declarations to use "class" instead of "struct".

Now you can parse your Think C code as C++.  This works quite well,
I'm told.

I don't know if Apple is planning to distribute MacBrowse w/o MacApp,
although I believe it's on the ETO CD-ROM which APDA sells.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Paco Xander Nathan)
Subject: index
Message-ID: <9011261701.AA08386@neuromancer>
Newsgroups: fa.think-c
Lines: 1
Date: 26 Nov 90 17:40:04 GMT

index










Path: ucivax!gateway
From: [e-mail] (Jennifer S Lanham)
Subject: (none)
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 54
Date: 27 Nov 90 23:44:44 GMT

Hello,

I am using the the oop capabilities of ThinkC 4.0.2.
I have a link error which I cannot resolve. The message is
"undefined: aSubClassName::(aFileName.c)"

I have a file "RedObj.h" which has three class definitions:
#define _H_RedObj

#include "CObject.h" /*superclass*/

CL1 : CObject{
/*method and variable declarations/*
};


CL2 : CL1{
/*methods and variables declarations*/
};

CL3 : CL1{
/*methods and variable declarations*/
};

I have instances of each class declared in an xterns.h file
#include "RedObj.h"

extern CL1 *back;
extern CL2 *ring;
extern CL3 *target;

NOW,

In another file, I am initializing these instances...
#include "xterns.h"
#include "RedObj.h"
#include <oops.h>

back = new(CL1);
ring = new(CL2);
target = new(CL3);

The linker says that CL3 is undefined. The others are fine.
After checking the usual things like mispellings, missing block
terminators, I finally tried bizarre things like switching the order
of the original class declarations.

Any ideas as to the problem???

I have used this stuff since it came out in 4.0. I just don't understand
it!
Thank you for any ideas,
Jennifer
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Dave Francis)
Subject: floating point accuracy
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 28
Date: 28 Nov 90 20:47:53 GMT

Hello netters!

I have a roundoff problem when using floating point numbers in Think C 4.0.2.

I've written a function which takes a floating point number and returns
a string that can be used for displaying with QuickDraw.

The problem is that when I pass the value to be converted Think C changes
it to a less accurate number so when I generate the string I don't get exactly
what was passed in. Here's a example:

The number input is 2.314 but inside the routine it becomes 2.3139996765 or
something like that (I think becuase Think C passes floating point as
extended). Anyway when I generate the string the return is "2.313" if the
precision is set to 3 (the function also takes a precision parameter)
It gets worse if I pass a value which has less significant digits than the
precision. So the value 3.2 passed in with a precision parameter of 3
in some cases gets returned as "3.199", which is unexceptable for display
purposes if the user e ntered 3.2.

Is there a way to stop this loss of accuracy when passing floating point
values? Why is there  a loss of accuracy anyway? What should I do? Are
there any rounding functions out there or better float->string converters?


Help!!

Dave Francis  Sapphire Design Systems










Path: ucivax!gateway
From: [e-mail] (Mark Hartman)
Subject: Floating-point blues - Dave Francis
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 34
Date: 29 Nov 90 14:19:26 GMT

Dave Francis <[e-mail]> writes:

>I have a roundoff problem when using floating point numbers in Think C
>4.0.2.
>
>The problem is that when I pass the value to be converted Think C changes
>it to a less accurate number so when I generate the string I don't get exactly
>what was passed in. Here's a example:
>
>The number input is 2.314 but inside the routine it becomes 2.3139996765 or
>something like that (I think becuase Think C passes floating point as
>extended). Anyway when I generate the string the return is "2.313" if the
>precision is set to 3 (the function also takes a precision parameter)

This is a problem with any floating point number implementation on any
computer system, Dave.  There is no way to precisely express a non-integer
value using a floating-point system.

All solution sets to this problem that I know of require you to decide the
maximum number of places to the right of the decimal point which are usable
by your routine.  After you do this, the easiest solution is to add half
of the minimum expressable quantity you decided upon to the result (e.g. if
you decided that 3 places were all they got, add .0005 to the result) and
truncate at that point.

By the way, if posting replies this way is not the proper way to do it (if
one is supposed to reply only privately), please let me know... thanks.

Good luck.
====
Mark Hartman, N6BMO           "What are you just standing there for?  Where
Applelink: N1083 or BINARY.TREE      do you think you are, DIS-ney World??"
Internet: [e-mail]                -- General Knowledge, from
uucp: ...{spsd,zardoz,felix}!dhw68k!emmayche                CRANIUM COMMAND










Path: ucivax!gateway
From: [e-mail]
Subject: Re: floating point accuracy
Original-From: ech (Ned Horvath)
Lines: 89
Date: 29 Nov 90 19:24:15 GMT
Phone: [phone]
Message-ID: <[e-mail]>
In-Reply-To: your message <internet3322334330> of Wed Nov 28 20:47:53 GMT 1990
>To: att!ics.uci.edu!think-c
Content-Type: Text
Content-Length: 3761
Newsgroups: fa.think-c
Message-Version: 2
Email-Version: 2
UA-Message-ID: <MAC-1.3.4A1-618034-ech-682>
UA-Content-ID: <PMX-PC-2.01A-000144-pegasus1-ech-2920>

------------ Original Message -------------
Hello netters!

I have a roundoff problem when using floating point numbers in Think C
4.0.2...

I've written a function which takes a floating point number and returns
a string that can be used for displaying with QuickDraw.
...
Is there a way to stop this loss of accuracy when passing floating point
values? Why is there  a loss of accuracy anyway? What should I do? Are
there any rounding functions out there or better float->string converters?


Help!!

Dave Francis  Sapphire Design Systems
--------- End of Original Message ---------

Floating point numbers always experience SOME loss of accuracy: consider
expressing 1/3 as a decimal number: the sequence of threes is periodic, but
infinite, and so there's always a bit of loss.  In short, it ain't the Mac,
and it ain't SANE, and it ain't a ThC problem.

This can't turn into a numerical methods lecture (course, career, ...) but
suffice to say that some algorithms are much more sensitive ("unstable") to
rounding error than others, so depending on how you manipulate the numbers,
you can get good or bad results.  Look in the (book) library under numerical
analysis: authors like Foreman Acton and Webb Miller will help you find good
(i.e. less sensitive) algorithms.

At display time, use an old APL trick, the "fuzz."  Decide what level of
accuracy is important to you, then add a bit to your result (or subtract a bit
if the value is negative) to allow rounding in the right direction.  If you
expect answers like xx.xxx, add .0005 before using sprintf.

If you're dealing with numbers with limited accuracy (like currency, interest
rates correct to 3 places, etc.) then you might consider avoiding floating
point altogether, using a fixed-point scheme, i.e. holding your numbers as
(long?) integers with an implicit scale factor.  Not only will you have better
accuracy, you'll have much better performance.  The Mac Toolbox Utilities
support a particular flavor of fixed-point (Fixed) -- see IM 1-467 -- with the
binary-point in the middle of a 32-bit word.  To display one of these using
sprintf, and three digits to the right of the decimal point:

    Fixed val;
...
    sprintf (buffer, "%d.%d",
        (int) (val >> 16),      /* integer part */
        FixRound (labs(val) * 1000) % 1000     /* decimal part */
    );

Using Fixed will still result in rounding error when you use FixRatio to
convert decimal to Fixed. An alternative approach, if you are dealing with a
fixed number of decimal digits, e.g. currency, is to hold an amount of money
as an integer in terms of thousandths-of-a-dollar.  Then, when you go to
display it, use something like

    typedef long Bucks;
    Bucks val;

    sprintf (buffer, "$%d.%d",
        val/1000,       /* dollars */
        val%1000/10);   /* cents */

Now, when you want to add such numbers, just do it.  To multiply, remember
that you have to renormalize: in this example, multiplying two of these
numbers gives us millionths of a dollar, so we have to post-divide by 1000 to
get back to thousandths:
    Bucks a, b;
...
    a = (a*b)/1000;
or, to take a percentage, say 8.5 percent:
    b = (a*85)/1000;    /* 8.5% == .085 == 85/1000 */

The bottom line -- and it's not for everyone! -- is that if you think about
your problem a bit, and work a bit harder, you can get high accuracy AND high
speed by avoiding floating point.  If the round-up-before-display works for
you, and the performance is adequate for your target audience, then just
ignore all this stuff.

At the risk of being tarred and feathered, COBOL handles this kind of thing
really well...

=Ned Horvath=
[e-mail]

Disclaimer: I haven't programmed COBOL since '71.  But I'd use it if I had the
right kind of problem...










Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: CPreferences
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 13
Date: 29 Nov 90 19:34:56 GMT

I've just written a class (based on someone elses's code) for reading and
writing application preferences. It looks for (or creates) a folder called
Preferences in the System Folder, and file in that folder with the same
name as the application. When the object is created, it opens this file
automatically, and provides Get and Put operations on the resources (yup,
it's a resource file). Dispose() closes the file.

I copied all the HFS-specific stuff verbatim, so I've no idea how that part
of it works, by the way...

Anybody want a copy?

Nick.










Path: ucivax!gateway
From: [e-mail] (Ken Hoover)
Subject: Re : CPreferences
Message-ID: <[e-mail]>
X-Mailer: Elm [version 2.1 PL1]
Newsgroups: fa.think-c
Lines: 29
Date: 29 Nov 90 23:15:34 GMT



> I've just written a class (based on someone elses's code) for reading and
> writing application preferences.
> [...]
> Anybody want a copy?
>

  Yes!  Yes!  I've been needing something like this for a while.

  However, you didn't include an email address, so I had to reply to
the list to be sure you get this.  Sorry folks.

> Nick.
>

                          - Ken

--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Ken Hoover - Senior Consultant       "In the East there is a great tree-
[e-mail]     structure that men call 'Corporate
Disclaimer : I claim dis...              Headquarters'..."
              dat is yours.                 - The Tao of Programming
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -














Path: ucivax!gateway
From: [e-mail] (Nick Rothwell)
Subject: CPreferences - oh-oh...
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 10
Date: 30 Nov 90 11:13:21 GMT

Hmm, I thought this might happen... twenty requests for it. What should I
do? I don't have easy FTP access to the States (though I can do it if
necessary), so can I just email the thing to someone to have it put on a
THINK-C archive or something? If so, fine, otherwise I'll just stuff and
BinHex the thing and mail it directly to the list. So (aside to the list
moderator, I guess, whose name/address I've forgotten, sorry:) if I can
mail this stuff to you for an archive site, I'll do so, otherwise I'll just
mail it to the list.

Nick.










Path: ucivax!gateway
From: [e-mail] (Dmitri Linde)
Subject: Easy way to make permanent and conditional break points
Message-ID: <[e-mail].>
Posted-Date: Fri, 30 Nov 90 08:52:49 CST
Newsgroups: fa.think-c
Lines: 48
Date: 30 Nov 90 15:15:11 GMT

Hi!

  There is a feature in Think-c debugger that I don't like: It doesn't
remomber break points.(I don't think of easy way to do this since
code may change a lot)^C
(Interrupt -- one more to kill letter)
^Cbolvan:3> mail [e-mail]
Subject: Easy way to make permanent and conditional break points
Hi!

  There is a feature in Think-c debugger that I don't like: It doesn't
remmember break points.(I don't think of easy way to do this since
code may change a lot). So, when I debug, I have to set the
same break points 100th time. Besides, there are conditional
break points, which are even worse...

  I found an undocumented(at least in the manual) function which will
help me.

      Debugger();
  It will bring up debugger.

  So, now I just have to insert this function in place, where I want
break point to be, and when it runs, it will function just like normal
break point.

  It does even better in case of conditional break points:
if(error) Debugger();  /* Let's look at some variables and see what's wrong*/


This useful function should be documented in next version of Think-c manual.
I found out about it by coincedence:
I typed:
void    Debugger(Str255 message)
{
  AddMessageToDebugWindow(message);
}

   Hope the above message does something useful...

  - Dmitri Linde
[e-mail]

P.S.  Sometimes people post messages saying that they've made something
interest
ing, does anybody want a copy?  Of' course they di want a copy, just
post your file to think-c archive, by ftping to ics.uci.edu, and uploading
into /incoming, and posting a short message onto the think-c list.










Path: ucivax!gateway
From: [e-mail] ("David S. McCormick")
Subject: disappearing pointers inside struct's
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 62
Date: 30 Nov 90 15:25:50 GMT

I have had some trouble with the address of pointers (the value returned
by *thePointer) which are fields within strucs. To wit, I was writing an
ansi-type c program (i.e., no Toolbox calls) to do a numerical
simulation. The struct contained a few pointers to dynamically allcoated
arrays . It looked something like this:

typedef struct myStruct {
        int     someValue;
        double  anotherValue;
        ...
        double  *aVector;
        double  **anArray;
} MYSTRUCT, *MYSTRUCTPTR;

The structs were allocated as:

MYSTRUCTPTR     aStructPtr;
aStructPtr = (MYSTRUCTPTR) malloc( (unsigned) sizeof( MYSTRUCT ) );

The vectors in the struct were allocated normally (using malloc; method
of Press et al. "Numerical Recipies in C" Cambridge Univ Press.) and
values were put in them. When I passed a MYSTRUCTPTR to a subroutine,
after some steps in the subroutine, the addresses of the array pointers
would change to totally different addresses and the data pointed to
would no longer be the originally values. Everything thereafter was
garbage. What gives? I thought that malloc() really called NewPtr() and
therefore the memory should be non-relocatable. The stuff shouldn't
shift, should it? Should I have been passing the array pointers to the
subroutine instead of the struct pointer?
As I was under time pressure I got around it by not using the struct,
rather just declaring all the fields and arrays individually [like a
good FORTRAN program]. I also know that I can get around it by declaring
the struct globally (since the memory gets allocated on the stack
(right?), but I don't necessarily want to have global scope.
I ran the program on an SE/30 sys6.0.5, ThinkC 4.0.2.

As a side issue, does anyone out there who does numerical work know a
way to allocate arrays dynamically like Numerical Recipies but do it
with NewHandle instead of an implicit call to NewPtr via malloc? Is this
worth doing?
This is the Numerial Recipies flavor of dynamic array allocation (except
that I use calloc() instead of malloc() as they do. These methods have
proved bullet-proof for numerical work in ThinkC:

float *vector(int nl, int nh)
{
/*    allocates a float vector with range [nl...nh] */
    float    *v;

  v = (float *) calloc((unsigned) (nh-nl+1), (unsigned) sizeof(float));
     if (!v) nrerror("allocation failure in vector()");
     return v-nl;
}

I would really appreciate any help on these issues. Thanks

David S. McCormick
MIT Earth, Atmospheric and Plantary Sciences
Cambridge, MA

[e-mail]
[e-mail]










Path: ucivax!gateway
From: [e-mail] (Cameron Christopher Long)
Subject: Graf3D in ThinkC
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 15
Date: 30 Nov 90 16:17:39 GMT

Hello,

I have recently become very interested in exploring the virtually
undocumented Graf3D routines. I have some simple MPW code for using
these routines, but am having trouble getting it to compile under ThinkC.

Does anyone know exactly what is required under ThinkC to access these
routines?

Thanks in advance,

Cameron Long

  Internet: [e-mail]
Applelink: d6788










Path: ucivax!gateway
From: [e-mail] (Ken Konecki)
Subject: Re: Easy way to make permanent and conditional break points
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail].>; from "Dmitri Linde" at Nov 30, 90 3:15 pm
X-Mailer: ELM [version 2.3 PL6]
Newsgroups: fa.think-c
Lines: 57
Date: 30 Nov 90 18:42:49 GMT

>
> Hi!
>
>   There is a feature in Think-c debugger that I don't like: It doesn't
> remomber break points.(I don't think of easy way to do this since
> code may change a lot)^C
> (Interrupt -- one more to kill letter)
> ^Cbolvan:3> mail [e-mail]
> Subject: Easy way to make permanent and conditional break points
> Hi!
>
>   There is a feature in Think-c debugger that I don't like: It doesn't
> remmember break points.(I don't think of easy way to do this since
> code may change a lot). So, when I debug, I have to set the
> same break points 100th time. Besides, there are conditional
> break points, which are even worse...
>
>   I found an undocumented(at least in the manual) function which will
> help me.
>
>       Debugger();
>   It will bring up debugger.
>
>   So, now I just have to insert this function in place, where I want
> break point to be, and when it runs, it will function just like normal
> break point.
>
>   It does even better in case of conditional break points:
> if(error) Debugger();  /* Let's look at some variables and see what's wrong*/
>
>
> This useful function should be documented in next version of Think-c manual.
> I found out about it by coincedence:
> I typed:
> void    Debugger(Str255 message)
> {
>   AddMessageToDebugWindow(message);
> }
>
>    Hope the above message does something useful...
>
>   - Dmitri Linde
> [e-mail]
>
> P.S.  Sometimes people post messages saying that they've made something
> interest
> ing, does anybody want a copy?  Of' course they di want a copy, just
> post your file to think-c archive, by ftping to ics.uci.edu, and uploading
> into /incoming, and posting a short message onto the think-c list.
>


--
Ken Konecki
"Eat well, stay fit, and die anyway"
e-mail:[e-mail]    -or-    ...!uunet!tellab5!kenk
U.S. Mail: 1271 Portchester Circle, Carol Stream, IL 60188










Path: ucivax!gateway
From: [e-mail] (Ken Konecki)
Subject: Re: Easy way to make permanent and conditional break points
Message-ID: <[e-mail]>
In-Reply-To: <[e-mail].>; from "Dmitri Linde" at Nov 30, 90 3:15 pm
X-Mailer: ELM [version 2.3 PL6]
Newsgroups: fa.think-c
Lines: 12
Date: 30 Nov 90 18:43:28 GMT


Ooops. Ignore that last message from me.

Won't the Debugger() call bring up Macsbugs if you have it installed?

Cheers,
    -Ken K
--
Ken Konecki
"Eat well, stay fit, and die anyway"
e-mail:[e-mail]    -or-    ...!uunet!tellab5!kenk
U.S. Mail: 1271 Portchester Circle, Carol Stream, IL 60188










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: Easy way to make permanent and conditional break points
Message-ID: <[e-mail]>
In-Reply-To: Dmitri Linde's message of 30 Nov 90 15:15:11 GMT <[e-mail].>
Newsgroups: fa.think-c
Lines: 20
Date: 30 Nov 90 19:25:08 GMT

The Debugger() call is actually a toobox trap, number 0xA9FF.  It
isn't documented because ThC's manuals don't document any Macintosh
calls -- although an exception should be made in this case, I think.

You may also find the trap DebugStr (number 0xA9FE) useful.  Its
prototype is:

void DebugStr(Str255 msg);    /* msg is a Pascal-format string */

It will     display a message in the Think C source window and halts
program execution.

Note that these calls are supported by all debuggers, including
MacsBug and TMON.

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Harald Hanche-Olsen)
Subject: disappearing pointers inside struct's
Message-ID: <9011301925.AA20264@hufsa>
In-Reply-To: "David S. McCormick"'s message of 30 Nov 90 15:25:50 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 18
Date: 30 Nov 90 19:30:37 GMT

   MYSTRUCTPTR     aStructPtr;
   aStructPtr = (MYSTRUCTPTR) malloc( (unsigned) sizeof( MYSTRUCT ) );

Hey wait a minute.  That malloc expects a size_t, which is long in
Think C.  sizeof() returns an int rather than size_t in Think, one of
those inconsistencies with ANSI C we all have grown to love.  So using
instead malloc((size_t)sizeof( MYSTRUCT )) ought to do the trick.

I will leave someone else to answer the other questions.  It's
impossible to tell whether using handles is worth the hazzle without
knowing your application, but if (like most of my programs) it just
allocates memory, plays with it and then exits, no it's not worth the
trouble.  My two cents' worth...

- Harald Hanche-Olsen <[e-mail]>
  Division of Mathematical Sciences
  The Norwegian Institute of Technology
  N-7034 Trondheim, NORWAY










Path: ucivax!gateway
From: [e-mail] (Phil Shapiro)
Subject: disappearing pointers inside struct's
Message-ID: <[e-mail]>
In-Reply-To: "David S. McCormick"'s message of 30 Nov 90 15:25:50 GMT <[e-mail]>
Newsgroups: fa.think-c
Lines: 27
Date: 30 Nov 90 19:40:54 GMT

I can't tell from your posting what your problem is, but I can make
some suggestions.

For one, memory allocated using malloc()/calloc() is nonrelocatable.
It is essentially allocated using NewPtr(), and it will not move
during your program's execution.  The problems you're running into
sound more like memory being trounced (or perhaps improper memory
allocation).

Here's the standard rules of thumb:

Make sure you're including <stdlib.h> in every file where you use
malloc().

Make sure that you prototype *all* your functions (or at least, those
that return non-integral (eg. long or pointer) results).

Always cast the result of sizeof() to either size_t (ANSI programs) or
Size (Mac programs).

hope this helps,

    -phil
----
   Phil Shapiro                           Technical Support Analyst
   Language Products Group                     Symantec Corporation
        Internet: [e-mail]










Path: ucivax!gateway
From: [e-mail] (Greg Stein)
Subject: Re: disappearing pointers inside struct's
Message-ID: <[e-mail]>
Newsgroups: fa.think-c
Lines: 37
Date: 30 Nov 90 20:01:38 GMT

> From: "David S. McCormick" <[e-mail]>
>
> typedef struct myStruct {
>         ...
>         double  *aVector;
>         double  **anArray;
> } MYSTRUCT, *MYSTRUCTPTR;
>
> [portions ommitted ]
>
> The vectors in the struct were allocated normally (using malloc; method
> of Press et al. "Numerical Recipies in C" Cambridge Univ Press.) and
> values were put in them. When I passed a MYSTRUCTPTR to a subroutine,
> after some steps in the subroutine, the addresses of the array pointers
> would change to totally different addresses and the data pointed to
> would no longer be the originally values. Everything thereafter was
> garbage. What gives? I thought that malloc() really called NewPtr() and
> therefore the memory should be non-relocatable. The stuff shouldn't
> shift, should it? Should I have been passing the array pointers to the
> subroutine instead of the struct pointer?

David,

The memory probably is non-relocatable.  You appear to be doing
everything correctly, but you did not provide information on how you
allocated aVector and anArray.  Particularly, anArray.  If you could
provide your method of allocating that, we might be able to solve your
problem.

Typically, many people forget the "double **anArray" is actually a
pointer to a vector of pointers to vectors of doubles.  If you don't
allocate anArray in this arrangement, you could probably see results
like yours (where things seem to mysteriously get trashed).

Greg Stein
Arpa: [e-mail]
UUCP: ..!{uunet,apple}!oracle!gstein